Sample Release Management Workflow

The following section provides a practical example of Release Management workflow.

Assumptions

• All rules databases share the same IVS, including production.
• After the development environments, the clients can follow any configuration /path that they choose. Clients should work with Oracle Consulting to help determine the best setup to meet their needs.

1. Create Environments:
   1. Development: Where configuration work on a project is completed. Unit testing is done in this environment.
   2. QA: Where full, non integration, QA (testing) is completed. No development work is done in this environment.
   3. Model: Where full QA (testing) is completed, including integration. This environment mimics exactly what the production environment will look like after project deployment. No development work is done in this environment.
   4. Production: Environment that holds all production data, and where customer servicing is performed. No development work is done in this environment.
2. Begin Testing and Configuration in Development Tracks: Development Track 1 and 2 are single environments where project work that will eventually migrate to production will take place. Within each development track is a QA environment. The configuration to a single QA environment will come only from its development track. When fully tested the QA is migrated to the Production Pipeline.

   Figure 8: OIPA Release Management – Multi-Track Migration Process

   

3. Promote Tested Configuration to the Production Pipeline: The Production Pipeline is a track that is used to fully test the developed configuration in a setting that mimics production. The Production Pipeline environment represents the current state of the production environment.

   Figure 9: OIPA Release Management Production Pipeline

   

4.  
   1. The development piece of the Production Pipeline will have all the configuration of Production, but will not have all the integrations. It will be updated with configuration from the various tracks (represented as Development Track 1 and 2). Configuration is merged into this track to ensure that needed configuration is not overwritten, as may be the case due to prior releases to production. Unit testing will be done in the Development environment.
   2. The QA environment in the Production Pipeline will contain the full testing of all configuration, which will mimic the new Production configuration.
5.  
   1. Along with the general QA environment, the Production Pipeline also includes a Model environment, or an environment that mimics the production environment, including all integrations.
   2. After all testing has been completed, the configuration will move to Production. At that point in time, all environments within the Production Pipeline track will contain exact copies, not including the integration connections.

The Source Control line in the diagram below represents the potential for the migrations to be integrated with an external source control system if desired.

Figure 10 – OIPA Release Management – Source Control